昨天，我在深圳开展了一场 Agentic Coding 训练营。
刚好遇上台风，深圳受到的影响比较直接。让我很感动的是，学员们还是从不同城市赶了过来，其中还有一位从北京来的学员。她周五晚上从北京飞过来，因为担心回不去临时周六晚上乘坐高铁回了北京。
这次训练营里，有一位来自清华建筑系的学员，也是我的好朋友，花姐。
课堂上，她问了我一个很有意思的问题：
有没有可能，一个人先把产品的所有功能都完整地规划好，再一次性交给 AI，让 AI 把整个产品开发出来？
这个问题看起来是在讨论 AI 的能力，但后来我发现，它真正触及的，可能是一个更深的问题：
一个人究竟能不能在产品出现之前，就把产品完整地想清楚？
一次想清楚，再开始开发
在课堂里，我一直强调一件事：
不要等到所有问题都想清楚以后，才开始动手。
这并不是说规划不重要，也不是说写 PRD、画流程图、梳理功能没有意义。相反，AI 编程尤其需要我们把想法表达得更清楚。
但我不太赞成一种完美主义式的开发方式：
先把所有功能、界面、流程、异常情况和用户需求全部想清楚，再把这一整套方案交给 AI，期待它一次性把产品做完。
花姐继续问我：
如果未来 AI 足够强呢？ 假设有一个人非常厉害，他真的能够把所有功能都想清楚，那他是不是就可以一次性交给 AI，让 AI 全部做完？
我当时没有直接回答“可以”或者“不可以”，而是和她一起换了一个角度。
我问她：
假设我们要完整复刻淘宝。 我把淘宝所有页面都截下来，给 AI 一千张截图，它能不能根据这些截图，重新做出一个完整的淘宝？
表面上看，一千张截图已经包含了大量信息。
商品页面长什么样、购物车在哪里、订单页面如何排列、按钮是什么颜色、不同状态如何展示，这些内容似乎都已经被记录下来了。
但我们都知道，仅仅依靠这些截图，很难真正做出一个可以运行的淘宝。
为什么？
因为一个产品真正复杂的部分，往往并不在画面里。
产品里有大量“看不见的东西”
当我们使用一个成熟产品时，能够看到的是页面、按钮、文字、图片和交互反馈。
但在这些表面之下，还存在着大量看不见的业务逻辑：
用户没有登录时会发生什么？
商品突然下架怎么办？
库存只剩一件，但有两个人同时付款怎么办？
订单已经支付，但商家没有发货怎么办？
退款、换货、优惠券、地址修改、物流异常分别如何处理？
不同身份的用户能够看到什么，又拥有什么权限？
数据如何存储？状态如何变化？不同功能之间如何互相影响？
这些内容很难通过截图完整地表达出来。
即使我们写了一份非常详细的 PRD，也很难在开发开始之前，穷尽所有可能出现的情况。
这不是因为产品经理不够聪明，也不是因为开发者能力不足，而是因为产品并不是一张静止的图。
它更像是一个运行中的系统。
只有当用户开始点击、输入、等待、返回、犯错，甚至做出一些我们没有预料到的操作时，这个系统真正的样子才会逐渐显现出来。
当这些看不见的部分没有被说清楚时，AI 只能根据它过去见过的产品和代码，去猜测这个功能“通常应该怎么工作”。
有时它猜得很好，有时它猜得不符合我们的真实需要。
所以，AI 生成出来的第一个版本，通常并不是最终答案。
它更像是一个提问：
你想要的是这样吗？
而我们需要通过这个初步结果，继续认识自己的需求。
给自己做产品，可能是最难的
后来我又想到，给自己做产品，可能比给别人做产品更加复杂。
因为很多时候，我们并没有自己想象得那么了解自己。
我们以为自己知道想要什么，但当产品真的出现在面前时，才会发现：
这个功能好像没有想象中重要。
原来我真正需要的不是这个按钮，而是减少一个操作步骤。
这个页面单独看没有问题，但放到完整流程中却显得多余。
我原本以为用户会这样使用，实际体验之后却发现，自己都不会这样使用。
更重要的是，人在思考的过程中，本身也会发生变化。
当我们看到一个更好的方案时，会改变原来的判断。
当我们把问题思考得更深入时，会重新理解最初的需求。
当产品从脑海里的想象变成可以点击的界面时，我们又会获得新的感受。
有时候，这些新的认识会修改一个功能；有时候，它们会推翻前面的整个结构。
所以，产品开发并不是把一个早已完整存在于脑海里的答案，逐字翻译成代码。
更多时候，我们是在开发过程中，逐渐发现答案。
产品不是先有鸡，还是先有蛋
回过头再想花姐的问题，我觉得它有点像“先有鸡还是先有蛋”。
如果一个人必须先把产品完全想清楚，才能开始开发，那么问题是：
在没有看到产品运行之前，我们怎么知道自己已经想清楚了？
但如果我们必须先把产品做出来，才能知道它应该是什么样子，那么又该从哪里开始？
其实，大多数产品都不是从一个完整答案开始的。
它们往往从一个模糊的念头、一个具体的问题，或者一个并不完善的原型开始。
我们先做出一点东西。
这个东西反过来刺激我们思考。
我们看到问题，修改它；看到新的可能，再继续往前走。
想法产生原型，原型改变想法；新的想法又产生新的原型。
鸡和蛋不是两个必须分出先后的答案，而是一个不断循环的过程。
同样，产品也不是“想清楚”和“做出来”两个相互分离的阶段。
思考本身就是开发的一部分，开发也会成为思考的工具。
如果未来真的出现 AGI 呢？
花姐后来又问：
如果未来真的有了 AGI，这个问题会不会被解决？
我觉得，首先要问的是：
所谓 AI“理解一个人”，究竟意味着什么？
它可以记住我们的对话，可以分析我们的偏好，也可以根据大量上下文，推测我们可能需要什么。
未来的 AI 也许会越来越了解我们的工作方式、表达习惯和判断标准。
但它真的能够完整地知道，我们脑海里正在想什么吗？
它能够知道那些连我们自己都还没有意识到的需求吗？
它能够提前知道，当我们看到某个结果之后，自己的想法会如何改变吗？
我对此并不确定。
因为问题可能不只是 AI 能不能理解人。
更根本的问题是：
人自己是否已经理解了自己？
如果一个需求在我们心里都还没有形成，那么 AI 很难直接把它读取出来。
如果我们的判断会随着体验而变化，那么即使 AI 完整执行了我们昨天的想法，今天的我们也可能已经不再认同那个结果。
因此，即使未来 AI 的能力大幅提升，产品创造可能依然不会变成一个完全单向的过程：
人提出完整要求，AI负责执行，产品一次成型。
它可能仍然是一种持续的对话。
只不过 AI 能更快地把想法变成原型，更主动地发现矛盾，也更早地提示那些我们没有看到的问题。
从一个故事，到一个真实产品
在训练营里，我还观察到了花姐学习 AI 编程时的另一个现象。
她很喜欢和 ChatGPT 对话。
当她谈论一个产品时，她会描述很多情景、人物和故事。ChatGPT 也能够沿着这些故事继续展开，把一个想法描述得非常完整、非常生动。
这其实是一种很重要的能力。
好的产品，往往就是从对人的观察和对情境的理解开始的。
建筑专业的训练，也让她更习惯从空间、关系、体验和生活场景出发，而不只是从一个功能列表出发。
但问题也恰恰出现在这里。
当一个故事已经被讲得很生动以后，下一步应该怎么做？
故事里的哪些部分需要成为功能？
哪些只是帮助我们理解用户的背景？
一个模糊的愿望，如何变成可以验证的需求？
一个生活情景，如何变成页面、数据、状态和交互？
当用户做出不同选择时，系统分别应该如何回应？
这里存在着一个很大的 Gap。
在 ChatGPT 中谈论产品，与真正做出产品，并不是同一件事。
前者更接近叙事、想象和意义建构，后者则需要把这些内容转化为结构、规则和可以运行的系统。
例如，一个人可能会说：
我想做一个能够理解我的 AI 助手。 它应该在我忙乱的时候帮助我整理任务，在我犹豫的时候给我建议，在我拖延的时候提醒我。
这是一个很好的产品愿景，也包含了非常具体的生活画面。
但要把它做成产品，还需要继续追问：
AI 通过什么判断用户正在忙乱？
哪些任务由 AI 自动整理，哪些必须经过用户确认？
“给建议”是提供一个答案，还是展示多个选择？
提醒到什么程度不会让人觉得被打扰？
AI 判断错误时，用户怎样纠正它？
这些纠正会不会影响下一次判断？
什么数据可以被记录，什么数据不能被读取？
从故事到产品，需要经过这样一层又一层的转译。
把脑海里的画面“纸面化”
训练营结束后，我一直在想：
无论对于 AI 编程的初学者，还是对于教授 AI 编程的老师，这可能都是一个非常值得研究的问题。
我们应该怎样帮助一个人，把脑海里的画面逐渐表达出来？
这里的“纸面化”，并不只是让他写一份长长的 PRD。
有些人擅长写功能，有些人擅长讲故事，有些人通过画图思考，有些人必须看到一个原型，才知道自己真正的感受。
我们也许需要一套中间语言，帮助不同的人完成几个阶段的转换：
从感受转化为情景；
从情景转化为问题；
从问题转化为需求；
从需求转化为行为；
从行为转化为流程；
从流程转化为功能；
从功能转化为数据、状态和规则；
最后，再把这些内容转化为可以运行和验证的产品。
AI 在这个过程中，不应该只是最后那个负责写代码的工人。
它也可以成为一个帮助我们澄清想法的合作者。
它可以追问：
这个场景里真正困难的是什么？
谁在什么情况下会使用这个功能？
用户完成这件事之前和之后，分别处于什么状态？
如果系统判断错误，会带来什么后果？
现在这个需求，是必须实现的，还是只是一个想象中的加分项？
这些问题不一定马上带来答案，但能够帮助我们看见自己还没有想清楚的部分。
AI 编程不是把思考外包出去
这次和花姐的对话，并没有让我觉得她的问题是错误的。
恰恰相反，我觉得这是一个非常好的问题。
因为很多人学习 AI 编程时，都会自然地产生一种期待：
既然 AI 写代码这么快，我是不是只要把要求表达得足够清楚，它就能够一次性把产品做完？
这种期待很容易理解。
我们过去常常认为，产品设计负责想清楚，开发负责做出来。现在开发的一部分被 AI 接管以后，我们自然会想，是否只需要把前面的“想清楚”做到极致，就可以彻底消除后面的反复。
但也许，反复并不是一种低效率。
有些反复，是因为需求不清；有些反复，是因为执行出错。但还有一些反复，是创造本身必不可少的过程。
我们通过做出来的东西，重新认识问题。
通过失败的方案，理解真正的限制。
通过一个并不完美的版本，发现过去看不见的可能。
所以，AI 编程并不意味着把思考外包给 AI。
它更像是让思考变得可以被快速看见。
以前，一个想法可能要等待几周，才能变成一个原型。现在，我们也许一天甚至几个小时，就能看到它最初的形态。
速度变快以后，我们不应该要求自己第一次就做对。
相反，我们可以更早地允许想法接受现实的检验。
不要等到想清楚一切
这次深圳训练营留给我的感受是：
我们当然应该认真规划，也应该努力把需求表达清楚。
但不必等到想清楚一切，才允许自己开始。
因为有些问题，只有开始以后才会出现。
有些需求，只有看到产品以后才会被意识到。
有些判断，只有在真实使用中才能形成。
我们不是先知，AI也不是。
AI无法替我们提前经历一个尚未出现的产品，也无法替我们确定未来的自己会喜欢什么。
但它可以陪我们更快地走进那个未知的过程。
我们提出一个还不成熟的想法，AI帮助它获得初步的形状；我们看到这个形状，再修改自己的理解；新的理解又推动产品继续变化。
在这个过程中，产品被一点点做出来，我们也在一点点认识自己。
所以，比起追求“一次性把产品全部想清楚”，我现在更关心另一个问题：
我们能不能建立一种更好的方法，让一个人脑海里的感受、故事和画面，逐渐变成可以讨论、可以验证、可以修改，最终可以运行的产品？
这可能是 AI 编程接下来真正重要的课题。
它不只是关于怎样让 AI 写出更多代码。
它也关于，我们怎样借助 AI，把那些还说不清楚的念头，慢慢变成现实。
最后，感谢花姐给了这么高的评价！
如果想了解下一期Agentic Coding训练营，欢迎 +v：xuezhirong233